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Abstract 

The cloud model's dependence on massive paral- 
lelism and resource sharing exacerbates the security 
challenge of timing side-channels. Timing Information 
Flow Control (TIFC) is a novel adaptation of IPC tech- 
niques that may offer a way to reason about, and ulti- 
mately control, the flow of sensitive information through 
systems via timing channels. With TIFC, objects such 
as files, messages, and processes carry not just content 
labels describing the ownership of the object's "bits," 
but also timing labels describing information contained 
in timing events affecting the object, such as process 
creation/termination or message reception. With two 
system design tools — deterministic execution and pac- 
ing queues — TIFC enables the construction of "timing- 
hardened" cloud infrastructure that permits statistical 
multiplexing, while aggregating and rate-limiting timing 
information leakage between hosted computations. 

1 Introduction 

Timing channels have been known and studied for 
decades Il7l[l3l, but have received a resurgence of atten- 
tion, particularly in the cloud computing context [i3][lT] . 
While decentralized information flow mechanisms (]9] 
[T4l and trusted computing hardware and security ker- 
nels fSlJlSl may protect cloud data and computations 
from break-ins and software vulnerabilities, these mech- 
anisms offer no defense against information leakage via 
timing side-channels, which are abundant in massively 
parallel environments. Information theft may be possi- 
ble even without active malware infection of a "victim" 
computation, as demonstrated in proof-of-concept via 
shared LI data cache 1101 . shared functional units 1121 . 
branch target cache ^, and instruction cache fl]. 

Although timing channels may represent a security 
risk in any shared infrastructure, the cloud model exacer- 
bates these risks in at least four ways, discussed in more 
detail elsewhere f3l and briefly summarized here. 

First, parallelism makes timing channel pervasive. 
Many processing resources yield timing channels, and 
even if one channel is exploitable only at low rate, an at- 
tacker who can gain co-residency with a victim on mul- 
tiple nodes and cores in a cloud ifTTl can multiply the 
leakage rate by the level of parallelism. 

Second, insider attacks become outsider attacks. An 



attacker would have to break into or get an account on 
private computing infrastructure before mounting a tim- 
ing attack, but on the cloud the attacker need only pur- 
chase the necessary CPU time from the provider 

Third, cloud-based timing attacks are unlikely to be 
caught. Timing attacks do not violate conventional sys- 
tem protection invariants, and are unlikely to set off 
alarms or leave a trail of evidence. Further, while the 
owner of a private machine can scan running compu- 
tations for malicious activity, a cloud provider has no 
prerogative to monitor its customers, and ironically, by 
doing so could invite privacy concerns or lawsuits. 

Fourth, the cloud business model depends on statis- 
tical multiplexing. The classic approach to limit timing 
channels, "reserving" hardware resources or timeslices 
to customers in a demand-independent fashion, would 
prevent the provider from oversubscribing and statisti- 
cally multiplexing hardware resources for efficiency. 

This paper introduces and informally explores an 
extension of decentralized information flow control 
(DIFC) techniques fO','!?! to the task of reasoning about 
and controlling timing side-channels between computa- 
tions hosted in a provider's cloud infrastructure. The 
approach currently addresses only timing side-channels 
internal to a cloud and not, for example, resulting from 
communication patterns visible on a public network Q . 
Furthermore, this paper merely explores one potential 
approach, which has not been rigorously formalized or 
experimentally validated; doing so remains future work. 

2 Timing Information Flow Control 

This section introduces Timing Information Flow Con- 
trol or TIFC, an extension of DIFC for reasoning about 
and control the propagation of sensitive information 
into, out of, or within a software system via timing chan- 
nels. With TIFC, an operating system can attach explicit 
labels or taints to processes and other objects, describ- 
ing what sources, types, and granularities of timing in- 
formation may have affected the state of the labeled ob- 
ject. Using these labels, the OS can enforce policies 
constraining how timing-derived information may flow 
among processes and affect their results. 

2.1 TIFC Model Overview 

Our TIFC model builds on Flume fSl, due to its sim- 
plicity and elegance. As in Flume, we assign labels to 
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system objects such as processes, messages, and files. A 
label can contain any number of tags, each of indicating 
that the labelled object has a particular "taint," or may 
be derived from information owned by a particular user 
Unlike conventional DIFC, however, TIFC labels reflect 
not only the content contained in such an object — i.e., 
the information contained in the bits comprising a mes- 
sage or a process's state — ^but also information that may 
have affected the timing of observable events associated 
with that object — a process starting or stopping, a mes- 
sage being sent or received, etc. Consistent with con- 
ventional, informal practices for reasoning about timing 
channels |7, 13 1, our TIFC model does not attempt the 
likely-infeasible task of eliminating timing channels en- 
tirely, but rather seeks to impose limits on the rate at 
which information might leak via timing channels. 

To distinguish content and timing taint explicitly, we 
give TIFC labels the form {Lc/Lt}, where Lq is a 
set of tags representing content taint, and Lt is a set 
of tags representing timing taint. As in Flume, content 
tags in the set Lc simply identify a user, such as Al- 
ice or Bob. Timing tags, however, we give the form Pf, 
where [/ is a user such as Alice or Bob, and / is a fre- 
quency representing the maximum rate with which user 
[/'s information might leak via this timing event, in bits 
per second. The frequency part of a timing tag may be 
oo, indicating that information leakage may occur at an 
unbounded rate. Thus, the label {A/Aoo,Bf} attached 
to a message might indicate that the content (bits) com- 
prising the message contains Alice's (and only Alice's) 
information, but that the timing with which the message 
was sent might contain (and hence leak) both Alice's and 
Bob's information — at an arbitrarily high rate in Alice's 
case, but up to at most / bits per second in Bob's case. 

2.1.1 Declassification Capabilities 

To enforce information security policies, we similarly 
build on Flume's model. We allow a process P to trans- 
mit information to another process or target object O 
only if P's label is a subset of O's, or if P holds de- 
classification capabilities for any tags in P that are not 
in O. A content declassification capability has the form 
[/~, and represents the ability to remove content tag U , 
as in Flume. TIFC also adds timing declassification ca- 
pabilities of the form C/7, representing the ability to 
declassify information carried by timing channels, at a 
rate up to frequency /. The "maximum-strength" timing 
declassifier U^ is equivalent to the content declassifier 
U^\ timing capabilities with finite frequencies represent 
weakened versions of these infinite-rate capabilities. 

Suppose process Pi has label {A/Aoo, Bf}, and pro- 
cess P2 has the empty label {—/—}. If process Pi were 
allowed to send a message to P2, this action would leak 
A's information via both message content and the tim- 



ing of the message's transmission, and would leak B's 
information (at a rate up to /) via timing alone. The sys- 
tem disallows this communication, therefore, unless the 
processes hold and use the relevant capabilities to adjust 
their labels before interacting. In particular: (a) Pi must 
hold the capability A^ and use it to remove its content 
tag A before sending the message; and (b) Pi must hold 
and use a timing capability BJ (or stronger) to declas- 
sify timing tag Bf before sending the message. 

2.2 Controlling Timing Channels 

Timing labels and capabilities alone would not be use- 
ful without mechanisms to control timing information 
flows. This section briefly introduces two specific tools 
useful for this purpose: deterministic execution and pac- 
ing. The next section will illustrate how we might em- 
ploy these tools in practical systems. 

Deterministic Execution: In general, a process whose 
label contains content tag U must also have timing tag 
Uoo, because the process's flow of control — and hence 
execution time — can vary depending on the [/-owned 
bits contained in its process state. The converse might 
also seem inevitable: if a process has timing tag Uf 
for any frequency /, and the process reads the current 
time via gettimeofday ( ) , for example, then the pro- 
cess's content subsequently depends on its execution 
timing, hence the process must have content tag U . Even 
if we disable system calls like gettimeofday () , 
conventional programming models — especially parallel, 
multithreaded models — enable processes and threads 
to depend on timing in many implicit ways, such as 
by measuring the relative execution speed of different 
threads. One thread might simply remain in a tight loop 
incrementing a shared memory counter, for example, 
which other threads read and use as a "timer" 

System-enforced deterministic parallel execution, as 
in Determinator |]4], offers a tool to decouple a pro- 
cess's timing and content labels. With system-enforced 
determinism, the OS kernel can prevent unprivileged 
processes from exhibiting any timing dependencies — 
even if the process maliciously attempts to introduce 
such dependencies — except via explicit inputs obtained 
through controlled channels. In effect, deterministic pro- 
cesses cannot "tell time" except via explicit inputs con- 
trolled by content labels. System-enforced determinism 
thus makes it "safe" for a process's content and tim- 
ing labels to differ If a process's explicit inputs were 
derived from user A's information, but its execution 
timing was also affected by S's information at rate /, 
we give the process the label {A/Aoo, Bf} rather than 
{A, B/Aoo, S/}, safe in the knowledge that system- 
enforced determinism prevents i3's "timing domain" in- 
formation from leaking into the process's "content do- 
main" (its explicit register/memory state). 



Pacing: Processes often interact with each other and 
with the external world via queued messages or I/O, and 
we leverage "traffic shaping" techniques common in net- 
working to limit the rate at which information might can 
across these queues via timing channels. We assume that 
we can pace the output of a message queue, such that 
regardless of how messages build up in the queue, the 
queue's output "releases" at most one message per tick 
of a recurring timer, firing at some frequency /. After 
each l//-time period, the queue's output releases ex- 
actly one message if the queue is non-empty, and no 
message if the queue is empty. Between clock ticks, 
the queue releases no information at all. Ignoring in- 
formation contained in the content and order of queued 
messages — which we control via content labels — we see 
that a paced queue leaks at most one bit of timing infor- 
mation per l//-time period: namely, whether or not the 
queue was empty at that particular timer tick. 

If messages flowing into a paced queue have a timing 
tag of U's for f > f (including /' = cxd), we can safely 
"downgrade" those timing tags to Uf at the queue's out- 
put, if the queue is paced at frequency /. If messages 
with label {A/Aoo,Boo} flow into a pacer with fre- 
quency /, for example, for example, then messages at 
the queue's output have label {A/Af, Bf}. While we 
for now can offer only an intuitive argument for the cor- 
rectness of this rate-limiting principle, a formalized ar- 
gument remains for future TIFC model development. 

3 Using TIFC: Case Studies 

We now illustrate TIFC with three simple examples, in 
which two customers — Alice and Bob — each wish to 
perform a privacy-sensitive computation on hardware 
managed by a trusted cloud provider Each customer de- 
sires strong assurance that his data cannot leak to other 
customers above a well-defined rate — even if his code 
is infected with malware that attempts to leak his data 
via timing channels. We make the simplifying assump- 
tion that timing channels arise only from shared com- 
pute resources, such as processor cores and the caches 
and functional units supporting them. We neglect for 
now other sources of timing channels, such as those aris- 
ing from network communication paths either within the 
cloud or between cloud and customers ifTTl . although 
this TIFC model may extend to other channels as well. 

Dedicated Hardware Scenario: The first example, in 
Figure lHa), illustrates a "base case" scenario, where 
the cloud provider controls timing channels merely by 
imposing a fixed partitioning of hardware compute re- 
sources between Alice and Bob. Alice submits compute 
job requests via a cloud gateway node that the provider 
dedicates exclusively to Alice, and similarly for Bob. 
Each customer's gateway forwards each job to a com- 



pute core, on the same or another node, that is also ex- 
clusive to the same customer The gateway nodes attach 
TIFC labels to each incoming request, and the provider's 
OS kernel or hypervisor managing each compute core 
uses these labels to prevent either customer's compute 
jobs from leaking information to the other via either the 
content or timing of messages within the cloud. 

Figure [Ttb) and (c) illustrates the (intuitively trivial) 
reason this example provides timing isolation, by con- 
trasting the system's timing when Bob submits a "short" 
job (b) with the timing when Bob submits a "long" 
job (c). Since Alice's job runs on a separate compute 
core from Bob's, Alice's job completion time depends 
only on the content of that job and Alice's prior jobs — 
information represented by the timing tag Aoo — and is 
not "tainted" by any timing dependency on Bob's jobs. 

Fixed-Reservation Timeslicing: Figure |2ta) shows a 
less trivial example, where a shared compute core pro- 
cesses both Alice's and Bob's jobs on a "fixed reserva- 
tion" schedule that does not depend on either Alice's or 
Bob's demand for the shared core. The shared compute 
core maintains and isolates the state of each customer's 
job using standard process or virtual machine mecha- 
nisms. The scheduling of these per-customer processors 
onto the shared core, however, is controlled by a separate 
entity we call the reservation scheduler. The scheduler 
conceptually mns on its own dedicated CPU hardware, 
and sends a message to the shared compute core at the 
beginning of each timeslice indicating which customer's 
job to run next. The code implementing the scheduling 
policy need not be trusted for information flow control 
purposes, as long as trusted code attaches and checks 
TIFC labels appropriately. In particular, the scheduler 
and the messages it sends have the empty label {—/—}, 
which allows the scheduler's messages to affect the tim- 
ing of Alice's and Bob's labeled jobs running on the 
shared core, without adding any new "taint." 

With its empty label, however, the reservation sched- 
uler cannot receive any messages from the shared core 
that might depend on either the content or timing of the 
customers' jobs. TIFC enforcement prevents the sched- 
uler from obtaining feedback about whether either Al- 
ice's or Bob's processes actually demand CPU time at 
any given moment, forcing the scheduler to implement 
a "demand-insensitive" policy, which isolates the tim- 
ing of different customers' jobs sharing the core, at the 
cost of wasting shared core capacity. Figure I2b) and 
(c) shows execution schedules for the shared core in the 
cases in which Bob's job is short or long, respectively, 
illustrating why Alice's job completion time depends 
only on Alice's information — hence the timing label of 
Aoo — though Bob's job may have executed on the same 
core during different (demand-independent) timeslices. 
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Figure 1: Labeling Scenario: Private Per-Client Hardware Resources 
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Figure 2: Labeling Scenario: Shared Resource with Reservation-based Scheduling 
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Figure 3: Labeling Scenario: Shared Resource with Demand-driven Scheduling 



Statistical Multiplexing: The above scenarios em- 
body well-known timing channel control techniques [T, 
\T3\, to which TIFC merely adds an explicit, analyz- 
able and enforceable labeling model. These standard 
techniques unfortunately undermine the cloud business 
model, however, by eliminating the cloud provider's 
ability to obtain efficiencies of scale through oversub- 
scription and multiplexing |3|. Figure |3] illustrates a fi- 
nal scenario that does allow statistical multiplexing, at 
the cost of a controlled-rate timing information leak. 

As above, this scenario includes a shared compute 
core and a separate scheduler. Instead of the empty 
(minimum) label, however, we now give the scheduler a 
"high" (maximum) label containing all customers' con- 
tent and timing taints. This label allows the scheduler 
to receive demand information from the shared com- 
pute core, and even to receive messages from customers' 
jobs themselves containing explicit scheduling requests 
or "performance hints." Since the scheduler's content la- 
bel (A, B) is higher than the content labels of either Al- 
ice's or Bob's jobs, TIFC disallows the scheduler from 
sending messages to Alice or Bob, or otherwise affecting 
the content (process state) of their jobs. 

The scheduler can send messages to the shared com- 
pute core's trusted control logic, however, to control 
which customer's jobs run in a particular timeslice. The 
shared core runs jobs deterministically, ensuring that re- 
gardless of how the scheduler runs them, each job's re- 
sult content depends only on that job's input content and 
not on execution timing. The scheduler's control mes- 
sages therefore "taint" all jobs with the timing tags — but 
not the content tags — of all customers. The results of Al- 
ice's job, for example, has the label {A/Aao, Boo), indi- 
cating that the result content contains only Alice's infor- 
mation, but the job's completion timing may also contain 
Bob's information. Without additional measures, this 
high timing label would prevent Alice's gateway from 
sending Alice's job results back to Alice, since the tim- 
ing of these job completion messages could leak Bob's 
information at an arbitrarily high rate. 

To rate-limit this timing leak, we assume that when re- 
questing service from the cloud provider, Alice and Bob 
agreed to allow timing information leaks up to a specific 
rate / fixed throughout this particular cloud. To enforce 
this policy, the cloud provider inserts a pacer on the path 
of each customer's job results queue, which releases the 
results of at most one queued job at each frequency / 
"tick" of a trusted provider-wide clock. Since all cus- 
tomers allow timing information leaks up to rate /, each 
user's gateway node grants all other gateways a timing 
declassification capability for rate /: thus, Alice's and 
Bob's gateways can declassify each others' timing la- 
bels up to rate /. The TIFC rules thus allow Alice's job 
results to flow back to Alice at up to / jobs per second. 



leaking at most / bits per second of Bob's information. 
Figure|3lb) and (c) compares two execution schedules 
resulting from Bob's job being "short" and "long," re- 
spectively. Due to demand-sensitive multiplexing, each 
job's completion time depends on the prior jobs of all 
users, which may mix all users' information at arbitrary 
rate. Alice's output pacer, however, delays the release 
of each job's results to a unique clock tick boundary, 
"scrubbing" this timing channel down to the frequency 
/ at which the gateways can declassify the timing labels. 

4 Conclusion 

While TIFC may represent a promising approach to 
hardening clouds against timing channels, much work 
remains. We are in the process of formalizing the model 
and security arguments, and implementing it in an exten- 
sion of Determinator (|4l for experimental validation. 
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